Add support for per-module versions to core#247
Add support for per-module versions to core#247mharriger wants to merge 2 commits intogit-commit-id:masterfrom
Conversation
…ule basedir is git repo root.
| @Nonnull File dotGitDirectory, | ||
| @Nonnull Properties properties) throws GitCommitIdExecutionException { | ||
| if (cb.getPerModuleVersions()) { | ||
| throw new GitCommitIdExecutionException("The native git provider does not support per module versions."); |
There was a problem hiding this comment.
First thanks for your contribution, maybe it is due to the fact that I never fully understood this "per module" request, but could you outline why the native git does not support this feature (maybe by explaining what this "per module" even means?).
I personally would kinda dislike the fact that certain features of the plugin are not supported by all providers (jgit/git)....
There was a problem hiding this comment.
Thanks for considering this PR! Sorry for taking a while to get back to you, gmail sent the GitHub notification to the wrong folder.
There is no reason that I know of that native git couldn't support this. I guess that error message should have indicated it is not implemented (yet), not that it is not supported by the provider. I mostly just ported an existing PR to the current codebase, and that PR only implemented this functionality for JGit. I could look at adding it to the native git provider, if that's what is needed to get this PR done.
As to the "why" for this change:
Our project is structured like this (with many more modules in practice):
ParentPOM
| - ModuleA
| - ModuleB
| - ModuleC
| - ModuleC1
| - ModuleC2
Both the POM inheritance and the filesystem layout follow this hierarchy.
When building a module (e.g. ModuleC2), I want to determine the last commit ID that affected its folder—similar to running:
git log .\ModuleC\ModuleC2
I can then attach the git.properties file as an artifact when deploying the module. Later, when building the full application, I can aggregate the git.properties files and publish a document with the last commit ID to modify each module. This makes it easy to identify which modules changed between two releases.
This process is especially valuable because the software is subject to strict certification requirements. If we can show that certain modules have not changed between versions, we can significantly reduce the amount of documentation required for certification.
2 participants
Context
This is an adaptation of #535 from the git-commit-id-maven-plugin repo to the current codebase.
Add an option perModuleVersions which when set causes the plugin to only consider commits affecting paths within the current module's folder (that is, the folder containing the current pom.xml).
This provides the support needed to implement Issue #136 in the Maven plugin.
Contributor Checklist
mvn clean packagecheckstylecoding style definition:mvn clean verify -Pcheckstyle -Dmaven.test.skip=true -B